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OBJECT-ORIENTED INSTRUCTION SET FOR 
5 RESOURCE -CONSTRAINED DEVICES 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent disclosure as it 
10 appears in the Patent and Trademark Office patent files or 
records, but otherwise reserves all copyright rights 
whatsoever. 

CROSS REFERENCE TO RELATED APPLICATIONS 

The following applications are incorporated herein 
15 by reference in their entirety: 

"Architecture-Neutral Exception Handling" and 
"Token-Based Linking," each naming Joshua B. Susser and 
Judith E. Schwabe as inventors, which are being filed 
concurrently with the present application; and 
20 "Virtual Machine with Securely Distributed Bytecode 

Verification," naming Moshe Levy and Judy Schwabe as 
inventors, filed April 15, 1997. 

In addition, an Appendix entitled "Java Card™ 
Virtual Machine Specification: Java Card Version 2.1" is 
25 attached to this application and forms a part of the present 
specification. 



BACKGROUND 

The present invention relates, in general, to 
object-oriented, architecture -neutral programs for use with 
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resource-constrained devices such as smart cards and the 
like . 

A virtual machine is an abstract computing machine 
generated by a software application or sequence of 
5 instructions which is executed by a processor. The term 
"architecture-neutral" refers to programs, such as those 
written in the Java™ programming language, which can be 
executed by a virtual machine on a variety of computer 
platforms having a variety of different computer 
10 architectures. Thus, for example, a virtual machine being 
executed on a Windows™-based personal computer system will 
use the same set of instructions as a virtual machine being 
executed on a UNIX™-based computer system. The result of 
O the platform- independent coding of a virtual machine's 

f%\ 15 sequence of instructions is a stream of one or more 
4* bytecodes, each of which is, for example, a one-byte-long 

r* numerical code. 

p Use of the Java programming language has found many 

^ applications including, for example, those associated with 

q 2 0 Web browsers. 

HI The Java programming language is object-oriented. 

St In an object-oriented system, a "class" describes a 

§ y 

tf| collection of data and methods that operate on that data. 

Taken together, the data and methods describe the state of 

25 and behavior of an object. 

Java also is verifiable such that, prior to 
execution of an application written in the Java programming 
language, a determination can be made as to whether any 
instruction sequence in the program will attempt to process 

3 0 data of an improper type for that bytecode or whether 

execution of bytecode instructions in the program will cause 
underflow or overflow of an operand stack. 
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A Java™ virtual machine executes virtual machine 
code written in the Java programming language and is 
designed for use with a 32 -bit architecture. However, 
various resource-constrained devices, such as smart cards, 
5 have an 8 -bit or 16 -bit architecture. 

Smart cards, also known as intelligent portable 
data-carrying cards, generally are made of plastic or metal 
and have an electronic chip that includes an embedded 
microprocessor to execute programs and memory to store 

10 programs and data. Such devices, which can be about the 
size of a credit card, typically have limited memory 
capacity. For example, some smart cards have less than one 
kilo-byte (IK) of random access memory (RAM) as well as 
limited read only memory (ROM) , and/or non-volatile memory 

15 such as electrically erasable programmable read only memory 
(EEPROM) . The limited architecture and memory make it 
impractical or impossible to implement the full Java Virtual 
Machine on the device . 

Furthermore, smart cards come with a variety of 

2 0 processors and configurations. Thus, it is desirable to 

provide a pi at form- independent programming language that can 
be executed on such a resource -constrained device. 



SUMMARY 

In general, a verifiable, object-based, type-safe 
25 and pointer-safe instruction set is described for 

application software programs which can be downloaded to and 
executed on a range of resource-constrained devices. 

According to one aspect, an application software 
program includes an object-oriented, verifiable, type-safe 
30 and pointer- safe sequence of instructions residing on a 

computer- readable medium. The program can be loaded to and 
executed by a resource-constrained device that is based on 

3 



an architecture of fewer than 32 bits, such as a 16 -bit or 
8 -bit architecture . 

According to another aspect, an application software 
program includes an object-oriented, verifiable, type-safe 
5 and pointer- safe sequence of instructions residing on a 

computer- readable medium. The program can be loaded to and 
executed by a resource -constrained device having random 
access memory with a capacity of no more than about 64K. 

Various implementations include one or more of the 

10 following features. For example, each instruction can 
include an 8 -bit operation code, and the sequence of 
instructions can be hardware platform- independent . In some 
implementations, the sequence includes instructions that 
were previously converted from at least one Java class file 

15 with at least some references to a constant pool transformed 
to inline data. For example, the instructions can include 
operation codes and operands. Some references to the 
constant pool can be inlined into operands, and some 
references to the constant pool can be inlined into 

20 operation codes. 

Similarly, in some embodiments, the instructions can 
be executed by a device that supports multiple data types. 
The sequence of instructions can include data manipulation 
instructions each of which is specific to a particular data 

25 type. In some implementations, the data type associated 
with each data manipulation instruction is selected from 
among one of the following types: an 8 -bit signed two's 
complement integer numeric type, a 16-bit signed two's 
complement integer numeric type and a 32-bit signed two's 

30 complement integer numeric type. Additionally, the 

instructions can be executed by a device that supports 
multiple reference types each of which is selected from 
among one of the following types: a class type, an interface 



type and an array type. Furthermore, the program can 
include one or more composite instructions for performing an 
operation on a current object. 

According to another aspect, a resource -constrained 
device includes memory for storing an application software 
program comprising an object-oriented, verifiable, type-safe 
and pointer-safe sequence of instructions. The device also 
includes a virtual machine implemented on a microprocessor. 
The virtual machine is capable of executing the sequence of 
instructions. In various embodiments, the device may be 
based on a limited architecture or may have a limited amount 
of memory. For example, in some implementations, the device 
includes random access memory having a capacity of no more 
than about 64K. In other embodiments, the microprocessor is 
based on an architecture of less than 32 bits, for example, 
a 16 or 8 -bit architecture. 

In other embodiments, an application-specific 
integrated circuit (ASIC) or a combination of a hardware and 
firmware can be used instead of a virtual machine running on 
a microprocessor. 

In one particular application of the invention, the 
resource -constrained device is a smart card. The smart card 
can include a virtual machine implemented on a 
microprocessor, wherein the virtual machine is capable of 
executing a sequence of instructions such as those described 
above . 

According to another aspect, methods are disclosed 
for using an application software program including an 
object-oriented, verifiable, type-safe and pointer-safe 
sequence of instructions. The software program can be 
received in a resource-constrained device having, for 
example, either limited memory or based on a limited 
architecture. The sequence of instructions then can be 



executed on the resource-constrained device. In some 
implementations, the software program can be accessed over a 
computer network such as the Internet prior to downloading 
it onto the device. When the program is downloaded to the 
5 resource-constrained device, constant pool indices that 
appear in the received set of instructions can be 
transformed to corresponding data values. 

Various implementations include one or more of the 
following advantages. By supporting many, although not all, 

10 of the features of the Java language and by using the same 
semantics as the Java class files, platform- independent 
virtual machine code can be written to be executed by a 
smart card or other resource-constrained device. 

The instruction set can inline certain data, which 

15 would otherwise appear as part of a constant pool, directly 
into operation codes or operands. Thus, the instruction set 
itself can incorporate certain information that would 
otherwise be stored in and obtained from a constant pool if 
one were using the Java class file format. By inlining some 

20 of the information directly into the instruction set, the 
size of the constant pool can be reduced, which can help 
reduce the amount of memory required to store the constant 
pool and can improve the execution speed of the bytecode. 
In some cases, inlining the information directly into an 

25 operation code can reduce the number of operands required 
for a particular instruction. Further inlining of 
information from a constant pool when the program is 
downloaded to the resource-constrained device can either 
eliminate the need to retain the constant pool on the device 

30 or reduce the size of the constant pool. 

Other features such as composite instructions for 
performing operations on the current object and the explicit 
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handling of 16-bit arithmetic can further reduce the length 
of a bytecode program. 

Other features and advantages will be readily 
apparent from the following detailed description, the 
5 accompanying drawings and the claims. 



BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 illustrates an exemplary system including a 
virtual machine residing on a smart card according to the 
invention. 

10 FIG. 2 is a flow chart illustrating a method of 

providing executable code to a smart card according to the 
invention. 

FIGS. 3A and 3B illustrate, respectively, an 
exemplary format of virtual machine instruction and an inner 
15 loop of execution of the virtual machine according to the 
invention. 

FIGS. 4A and 4B are tables of an exemplary set of 
operation codes for the virtual machine listed in numerical 
order by operation code and in alphabetical order by 
20 mnemonic, respectively. 

FIG. 5 is a list of data types which are supported 
by operation codes that exist for multiple data types 
according to the invention, 

FIG. 6A illustrates the format of an "iipush" 
25 instruction according to the invention, and 

FIG. 6B illustrates the format of a corresponding 
"ldc" instruction in the Java class file format. 

FIG. 7A illustrates the format of a "checkcast" 
instruction in the Java class file format, and 
3 0 FIG. 7B illustrates the format of a "checkcast" 

instruction according to the invention. 
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FIG. 8A illustrates the format of a family of 
u getf ield_T" instructions according to the invention, and 

FIG. 8B illustrates the format of a corresponding 
"getfield" instruction in the Java class file format. 
5 FIG. 9A and 9B illustrate how an implementation 

program on the smart card prepares virtual machine code for 
installation on the smart card according to one embodiment 
of the invention . 

FIGS. 10A and 10B illustrate alternative 
10 instructions for obtaining the same result according to the 
invention. 

FIG. 11A illustrates bytecodes for carrying out a 
mathematical expression using the Java class file format, 
and 

m 15 FIG. 11B illustrates bytecodes for carrying out the 

41 same mathematical expression according to the invention. 

'?* FIG. 12 is partial, non-exclusive list of 

CI resource -constrained devices with which the invention can be 

^ used. 

jl 20 DESCRIPTION 

St A verifiable, object-based, type-safe and pointer- 

r|| safe instruction set is described below for application 

^ software programs which can be downloaded to and executed on 

a range of resource-constrained devices. Resource- 
25 constrained devices are generally considered to be those 
that are relatively restricted in memory and/or computing 
power or speed, as compared to conventional desktop 
computers and the like. Although the particular 
implementation discussed below is described in reference to 
30 a smart card, the invention can be used with other resource- 
constrained devices including, but not limited to, cellular 
telephones, boundary scan devices, field programmable 
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devices, personal digital assistants (PDAs) and pagers, as 
well as other miniature or small footprint devices. 

Programs written with the instruction set described 
below are capable of being downloaded to and executed on 
5 resource-constrained devices having about sixty-four kilo- 
bytes (64K) of RAM or less. Some of the resource- 
constrained devices in which such programs can be executed 
may have no more than about sixteen kilo-bytes (16K) of RAM 
and others may have no more than about four kilo-bytes (4K) 

10 of RAM. Many of the devices also have limited amounts of 
other memory, such as no more than about twenty- four kilo- 
bytes (24K) of ROM, or no more than about 16K of non- 
volatile memory such as EE PROM. Similarly, some resource- 
constrained devices are based on an architecture designed 

15 for fewer than 32 bits. For example, some of the devices 
which can be used with the invention are based on an 8 -bit 
or 16-bit architecture, rather than a 32-bit architecture. 
Of course, applications using the instruction set described 
below are upward compatible and can be executed, for 

2 0 example, on other Java platforms provided equivalent device 
support is present. 

Referring to FIGS. 1 and 2, development of an applet 
for a resource -constrained device, such as a smart card 40, 
begins in a manner similar to development of other Java 

25 programs. In other words, a developer writes one or more 
JAVA classes (step 60) and compiles the source code with a 
JAVA compiler to produce one or more class files 10 (step 
62) . The applet can be run, tested and debugged, for 
example, on a workstation using simulation tools to emulate 

30 the environment on the card 40. When the applet is ready to 
be downloaded to the card 40, the class files 10 are 
converted to a converted applet (CAP) file 16 by a converter 
14 (step 64) . The converter 14 can be implemented as a Java 



application being executed by a desktop computer. The 
converter 14 can accept as its input one or more export 
files 12 in addition to the class files 10 to be converted. 
An export file 12 contains naming or linking information for 
5 the contents of other packages that are imported by the 
classes being converted. 

In general, the CAP file 16 includes all the classes 
and interfaces defined in a single Java package and is 
represented by a stream of 8-bit bytes. All 16-bit and 32- 

10 bit quantities are constructed by reading in two or four 

consecutive 8 -bit bytes, respectively. Among other things, 
the CAP file 16 includes a constant pool component 18 which 
is packaged separately from a method component 20. The 
constant pool component 18 can include various types of 

15 constants, ranging from numerical literals known at compile 
time to method and field references which are resolved 
either when the program is downloaded to the smart card 4 0 
or at the time of execution by the smart card. The method 
component 2 0 specifies the set of instructions to be 

2 0 downloaded to the smart card 4 0 and subsequently executed by 
the smart card. Further details of the structure of an 
exemplary CAP file 16 are discussed in the attached Appendix 
at pages 53 through 94 and in a publication by Sun 
Microsystems, Inc. entitled Vava Card Runtime Environment 

25 (JCRE) 2.1 Specification," (1998) which is incorporated 
herein by reference in its entirety. 

After conversion, the CAP file 16 can be stored on a 
computer-readable medium 17 such as a hard drive, a floppy 
disk, an optical storage medium, a flash device or some 

30 other suitable medium. 

The CAP file 16 then can be copied or transferred to 
a terminal 22 (step 66) such as a desktop computer with a 
peripheral card acceptance device (CAD) 24. In some 



embodiments, the terminal 22 can be connected to a network 
(not shown), such as the Internet, a local area network 
(LAN) or a wide area network (WAN) , which communicates with 
other computing devices such as a server. In such 
5 situations, the CAP file 16 can be accessed and transmitted 
to the terminal 22 over the network. The CAP file 16 also 
can be provided to the terminal 22 using a carrier wave, 
such as a network data transmission. 

The CAD 24 allows information to be written to and 

10 retrieved from the smart card 40. The CAD 24 includes a 
card port (not shown) into which the smart card 40 can be 
inserted. Once inserted, contacts from a connector press 
against the surface connection area on the smart card 4 0 to 
provide power and to permit communications with the smart 

15 card, although, in other implementations, contactless 

communications can be used. The terminal 22 also includes 
an installation tool 26 which loads the CAP file 16 for 
transmission to the card 40 (step 68) . 

The smart card 40 has an input /output (I/O) port 42 

2 0 which can include a set of contacts through which programs, 
data and other communications are provided. The card 40 
also includes an installation tool 46 for receiving the 
contents of the CAP file 16 and preparing the applet for 
execution on the card 4 0 (step 70) . The installation tool 

2 5 4 6 can be implemented, for example, as a Java program and 

can be executed on the card 40. The card 40 also has 
memory, including volatile memory such as RAM 50. The card 
40 also has ROM 52 and non-volatile memory, such as EE PROM 
54. The applet prepared by the controller 44 can be stored 

3 0 in the EEPROM 54. 

In one particular implementation, the applet is 
executed by a virtual machine 4 9 running on a microprocessor 
4 8 (step 72) . The virtual machine 49, which can be referred 



to as the Java Card™ Virtual Machine, need not load or 
manipulate the CAP file 16. Rather, the Java Card Virtual 
Machine 49 executes the applet code previously stored as 
part of the CAP file 16. The division of functionality 
5 between the Java Card Virtual Machine 49 and the 

installation tool 4 6 allows both the virtual machine and the 
installation tool to be kept relatively small. 

In general, implementations and applets written for 
a resource-constrained platform such as the smart card 40 

10 follow the standard rules for Java platform packages. The 
Java Virtual Machine and the Java programming language are 
described in T. Lindholm et al . , The Java Virtual Machine 
Specification (1997), and K. Arnold et al . , The Java 
Programming Language Second Edition, (1998) , which are 

15 incorporated herein by reference in their entirety. 

Application programming interface (API) classes for the 
smart card platform can be written as Java source files 
which include package designations, where a package includes 
a number of compilation units and has a unique name. 

20 Package mechanisms are used to identify and control access 
to classes, fields and methods. The Java Card API allows 
applications written for one Java Card-enabled platform to 
run on any other Java Card-enabled platform. Additionally, 
the Java Card API is compatible with formal international 

25 standards such as ISO 7816, and industry-specific standards 
such as Europay /MasterCard/Visa (EMV) . 

The smart card platform of the present invention 
supports dynamically created objects including both class 
instances and arrays. A class is implemented as an 

3 0 extension or subclass of a single existing class and its 
members are methods as well as variables referred to as 
fields. A method declares executable code that can be 
invoked and that receives a fixed number of values as 



arguments. Classes also can define or implement Java 
interfaces. An interface is a reference type whose members 
are constants and abstract methods. 

Individual instructions stored in the CAP file 16 
5 and subsequently downloaded to the smart card 40 include an 
8 -bit operation code (opcode) followed by either zero, one 
or multiple 8 -bit operands (FIG. 3A) . Some instructions 
have no operands and consist only of an opcode. The general 
form of the inner loop of execution of the Java Card Virtual 

10 Machine 49 is illustrated in FIG. 3B. When a method is 

invoked, the Java Card Virtual Machine 49 allocates a frame 
which has a set of local variables and contains an operand 
stack. Many of the operation codes discussed below take one 
or more values from the operand stack of the current frame, 

15 operate on them, and return results to the same stack. The 
operand stack also is used to pass arguments to methods and 
receive method results . 

Values from the operand stack must be operated upon 
in ways that are appropriate to their types. The Java Card 

2 0 Virtual Machine 4 9 supports two kinds of data types: 

primitive types and reference types. The numeric primitive 
types supported by the Java Card Virtual Machine 49 are: (1) 
"byte", whose values are 8-bit signed two's complement 
integers; (2) "short", whose values are 16 -bit signed two's 
25 complement integers; and, optionally, (3) "int", whose 
values are 32-bit signed two's complement integers. The 
Java Card Virtual Machine 49 also supports a "returnAddress" 
type, whose values are pointers to the operation codes in 
the instructions for the virtual machine. The 

3 0 reference types supported by the Java Card Virtual Machine 

49 are (1) "class" types; (2) "interface" types; and (3) 
"array" types. Those reference types are the same as the 
reference types used in the Java Virtual Machine. The Java 



Card Virtual Machine 49 is defined in terms of an abstract 
storage unit, which can be referred to as a word, which is 
sufficiently large to hold a value of the type "byte," 
"short," "reference," or "returnAddress . " Two words are 
5 sufficiently large to hold a value of the type w int." 

Multiple-byte operand data is encoded in big-endian order, 
in other words, with the high-order byte first. 

Various keywords, which cannot be used as 
identifiers or names of declared entities, are supported by 

10 the Java Card Virtual Machine 49. A list of the supported 
keywords is provided in the attached Appendix at page 11. 
The function and use of those keywords is the same as the 
corresponding keywords in the Java programming language . 
The operation codes which form the executable 

15 program stored in the method component 2 0 of the CAP file 16 
are designed to use the same semantics as that used in the 
class files 10 written in the Java language. Thus, for 
example, mathematical results and class hierarchies are 
preserved when the converter 14 transforms the Java class 

20 files 10 into the CAP file 16. Nevertheless, as will be 
evident from the following description, a sequence of 
instructions that can be executed by the Java Card Virtual 
Machine 49 differs from programs intended solely to be run 
by a system incorporating the Java Virtual Machine. Some of 

25 the differences are due to the more limited support of data 
types present in the instruction set discussed below. Other 
differences result from the fact that the instruction set 
discussed below is designed to be executable by a virtual 
machine residing on a resource-constrained device. Some 

30 details of the instruction set are intended to optimize the 
size or performance of either the Java Card Virtual Machine 
49 or the programs running on it. Such details include 
inlining constant pool data directly into the operation 



codes or operands, adding multiple versions of a particular 
instruction to handle different data types, creating 
composite instructions for operations on the current object, 
and explicitly handling 16-bit arithmetic. 
5 Referring to FIGS. 4A and 4B, an exemplary 

instruction set is provided for programs to be executed by 
the Java Card Virtual Machine 49. Each instruction is 
identified by a corresponding operation code (opcode) 
mnemonic and numerical representation. With the exception 

10 of two reserved opcodes, impdepl and impdep2, all of the 

opcodes typically can be used in a CAP file such as the CAP 
file 16. The instructions corresponding to the two reserved 
opcodes provide backdoors or traps to implementation- 
specific functionality implemented in software and hardware, 

15 respectively. Accordingly, the two reserved opcodes 

typically do not properly appear in the CAP file 16. They 
are typically used only in representations of programs that 
were placed on the smart card 4 0 by means other than receipt 
of a CAP file. 

2 0 As previously mentioned, each instruction includes 

an operation code followed by zero, one, or more operands. 
In other words, the instructions have the following general 
format : 

operation code 
25 operandi 

operand2 

Each word in the instruction format represents a single 8- 
bit byte or "bytecode." The instruction's opcode is its 

3 0 numeric representation. Each instruction also has a 

corresponding mnemonic which is its name. However, only the 
numeric representation is present in the virtual machine 
code in a CAP file such as the CAP file 36. Detailed 



explanations of each instruction including its function and 
effect on the operand stack appear in the attached Appendix 
at pages 97 through 215. 

Each data manipulation instruction is specific to a 
5 particular data type. The instruction set corresponding to 
the operation codes listed in FIG. 4A supports a subset of 
the features supported by the Java programming language. By 
supporting many, although not all, of the features of the 
Java language and by using the same semantics as the Java 

10 class files 10, pi at form- independent virtual machine code 
can be written to be executed by the smart card 40 or other 
resource-constrained device. 

As mentioned above, the instruction set for the Java 
Card Virtual Machine inlines certain data, which would 

15 otherwise appear as part of the constant pool 18, directly 

into the operation codes or operands. Thus, the instruction 
set itself incorporates certain information that would 
otherwise be stored in and obtained from a constant pool if 
one were using the Java class file format. Thus, when the 

2 0 one or more Java class files 10 are converted to the CAP 

file 16, at least some references to a constant pool are 
transformed to inline data in the bytecodes associated with 
the CAP file. 

For example, if the virtual machine 49 supports the 
25 data type "int," then the u iipush" operation code can be 

used to push an integer value onto the operand stack. The 
general format for the "iipush" instruction is illustrated 
in FIG. 6A, and the format of a corresponding "ldc" 
instruction from the Java class file format is shown in FIG 

3 0 6B. The "Idc" instruction includes the operand "index" 

which is an unsigned byte that is an index into a constant 
pool. In contrast, the "iipush" instruction, which is 
executable by the Java Card Virtual Machine 49, eliminates 



the need to refer to the constant pool when executing that 
instruction. Although the "iipush" instruction includes 
four operands, thereby increasing the length of the 
instruction, the slightly longer program can be offset by 
the savings in memory space which is achieved by eliminating 
the need to store additional information in the constant 
pool 18. 

Similarly, the "checkcast" operation code can be 
used to check whether an object is of a particular type. 
The general format for the "checkcast" instruction for the 
Java Card Virtual Machine 49 is illustrated in FIG. 7A, and 
the format of a corresponding "checkcast" instruction from 
the Java class file format is shown in FIG 7B. The data 
type for the Java Card Virtual Machine 49 has been inlined 
directly into the instruction, in contrast to the 
corresponding Java instruction in which the data type is 
obtained from a constant pool. By inlining some of the 
information directly into the instruction set, the size of 
the constant pool 18 that is stored in the CAP file 16 can 
be reduced. 

The foregoing examples illustrate how the 
instruction set for the Java Card Virtual Machine 49 inlines 
some information directly into an operand. In some cases, 
an additional form of inlining is provided by inlining 
information that would otherwise be stored in the constant 
pool 18 directly into an operation code. Thus, for example, 
the instruction set for the Java Card Virtual Machine adds 
multiple versions of several instruction to handle different 
data types so that those instructions appear as members of a 
family of related instructions which share a single 
description, format and operand stack diagram. Each 
instruction in such a family of instructions implicitly 
specifies the data type in the operation code itself. The 



table in FIG. 5 provides a list of the data types which are 
supported by instructions that exist for multiple data 
types. Wide and composite forms of instructions are not 
listed. Referring to FIG. 5, a specific instruction, with 
the data type incorporated into the operation code, is 
obtained by replacing the "T" in the instruction template in 
the opcode column by the letter representing the type in the 
type column. Where the column for a particular instruction 
is left blank, then no instruction exists supporting the 
particular operation on that data type. For example, there 
is a "load" instruction for the data type "short," but there 
is no "load" instruction for the data type "byte." 

With instructions that implicitly incorporate the 
data type into the operation code, the program can operate 
more quickly and with less data on the smart card 4 0 than 
would otherwise be required. Those advantages arise because 
the data type is directly encoded in the instructions rather 
than being obtained from an entry in the constant pool . For 
example, consider the family of "getfieldJT" instructions, 
which includes the instructions "getf ield_a, " "getfield b," 
tt getfield_s" and "getf ield_i . " The general format of the 
"getf ield_T" instructions for use with the Java Card Virtual 
Machine 49 is illustrated in FIG. 8A, which contrasts with 
the format of the corresponding "getfield" instruction in 
the Java class file format as shown in FIG. 8B. In the 
instructions for the Java Card Virtual Machine 49 (FIG. 8A) , 
the data type has been inlined not only into the 
instruction, but it has been inlined directly into the 
operation code. On the one hand, such features can reduce 
the amount of information stored in the CAP file 16 and also 
can reduce the number of operands required for the 
particular instruction. On the other hand, those features 
expand the number of distinct operation codes. 
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Whereas the type of inlining discussed with respect 
to the "iipush" and "checkcast" opcodes can be advantageous 
for instructions that tend to be less frequently used, the 
type of inlining discussed with respect to the "getfield t" 
5 family of instructions can be advantageous particularly for 
instructions that tend to be used more frequently. 

The foregoing examples illustrate how the 
instruction set for the Java Card Virtual Machine 49 
inherently inlines certain information. Another form of 

10 inlining information can occur when the CAP file 16 is 
downloaded to the smart card 40, as explained below. 

The installation tool 46 on the smart card 40 can be 
platform- specific and allows the actual storage of the 
contents of the CAP file 16 to be determined based on the 

15 particular platform receiving and preparing the virtual 

machine code for execution. Thus, in some implementations, 
the CAP file 16 may be stored on the smart card 40, or other 
resource -constrained device, in a manner that differs from 
the manner in which it was received by the smart card. For 

2 0 example, in some cases, when the CAP file 16 is installed on 
the card 40, the installation tool 46 can link the contents 
of the CAP file so that the size of the constant pool 18 can 
be reduced, and in some cases, so that the constant pool 
need not be retained or stored on the card. That can be 

25 accomplished by converting the constant pool indices that 
appear as part of the code in the CAP file 18 to the 
corresponding data at the time of installation, as 
illustrated in FIGS. 9A and 9B. For example, an index to 
the constant pool 16 can be replaced by an index to the 

30 appropriate field in the object. Thus, the virtual machine 
code stored on the card 4 0 will already have the data 
incorporated within it prior to the time of execution. The 
virtual machine code, with the constant pool 18 removed, 



reduces some of the indirection inherent in a program which 
uses a constant pool. The amount of memory required to 
store the bytecodes on the smart card 40 can, therefore, be 
reduced, and the execution time for the program also can be 
5 reduced. Of course, in other implementations, the 

installation tool 46 may retain the constant pool 18 when 
the CAP file 16 is downloaded to the smart card 40. 

As previously mentioned, the instruction set for the 
Java Card Virtual Machine also includes composite 

10 instructions for performing operations on the current 

object. In other words, some of the instructions that are 
executable by the Java Card Virtual Machine 4 9 allow 
multiple instructions to be collapsed into a single 
instruction. In particular, instructions that include a 

15 u this" operation, such as the family of w getf ield_T_this" 
instructions and the family of "putf ield_T_this" 
instructions, effectively concatenate multiple instructions. 
In general, the "this" operation operates on the current 
object. For example, to fetch a field from the current 

2 0 object, one could use a combination of the u aload_0" 

instruction and a u getf ield_a" instruction as shown in FIG. 
10A. Alternatively, one can use the single instruction 
"getf ield_T_this" as illustrated in FIG. 10B. Use of the 
latter instruction can result in a smaller and faster 
25 program code. As previously noted, such features are 

particularly advantageous in resource-constrained devices 
such as the smart card 40. 

The instruction set for the Java Card Virtual 
Machine also handles 16 -bit arithmetic explicitly. To 

3 0 illustrate how 16 -bit arithmetic is handled, consider a 

situation in which u a," u b" and "c" have been declared as 
"short" type variables, and the expression w c = (short) a + 
b;" is to be compiled. The bytecodes written in the Java 



class file format are shown in FIG. 11A. As can be seen 
from FIG. 11A, five opcodes are used to load the values "a" 
and "b," to add the values "a" and "b," to convert the 
resulting integer type into a short type, and to store the 
5 result. In contrast, only four opcodes are needed to obtain 
and store the result using the instruction set for the Java 
Card Virtual Machine 49 which obviates the need to convert 
the integer type result into a short type. Furthermore, in 
addition to using fewer bytecodes, the size of the stack can 

10 be reduced by as much as fifty percent because the Java Card 
Virtual Machine operates on 16-bit quantities rather than 
32 -bit quantities . 

An object-oriented, verifiable instruction set is, 
therefore, provided and allows a file with virtual machine 

15 bytecode to be stored on a computer-readable medium. Such a 
file can be downloaded to the resource-constrained device so 
that the bytecode can be executed by the resource- 
constrained device. 

Although a virtual machine 49 running on a 

20 microprocessor 48 has been described as one implementation 
for executing the bytecodes on the smart card 40, in 
alternative implementations, an application- specif ic 
integrated circuit (ASIC) , or a combination of hardware and 
firmware can be used as a controller for executing 

25 downloaded code instead. 

Furthermore, although the invention can be 
implemented using the operation codes listed in FIGS. 4A and 
4B, other operation codes and corresponding instruction sets 
having certain characteristics are suited for implementing 

30 the invention as well. Such characteristics include 

verif iability, type safety, pointer safety, object-oriented, 
dynamically linked, virtual machine-based, platform- 
independence, and use of the same semantics as the Java 



language, although not all of those characteristics need to 
be present in a particular implementation. 

As previously discussed, the Java Card instruction 
set can be used with a variety of different resource- 
5 constrained devices, some of which are listed in FIG. 12. 

Other implementations are within the scope of the 
following claims. 

What is claimed is: 
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1 1 . An application software program comprising an 

2 object-oriented, verifiable, type-safe and pointer-safe 

3 sequence of instructions residing on a computer-readable 

4 medium, wherein the program can be loaded to and executed by 

5 a resource-constrained device that is based on a processor 

6 architecture of fewer than 32 bits. 

1 2 . The software program of claim 1 wherein the 

2 program can be executed by a resource -constrained device 

3 based on a 16-bit processor architecture. 

1 3 . The software program of claim 1 wherein the 

2 program can be executed by a resource-constrained device 
0 3 based on an 8 -bit processor architecture. 

4« 1 4. The software program of claim 1 wherein each 

2 instruction includes an 8 -bit operation code. 

1 5 . The software program of claim 1 wherein the 

P 2 sequence of instructions is hardware plat form- independent . 

ii 

S= 1 6. The software program of claim 1 wherein the 

2 instructions were converted from at least one Java class 

^ 3 file and wherein at least some references to a constant pool 

4 were transformed to inline data. 

1 7 . The software program of claim 6 wherein the 

2 instructions comprise operation codes and operands and 

3 wherein at least some references to the constant pool are 

4 inlined into operands in at least some of the instructions. 
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1 8 . The software program of claim 6 wherein the 

2 instructions comprise operation codes and operands and 

3 wherein at least some references to the constant pool are 

4 inlined into operation codes in at least some of the 

5 instructions. 

1 9. The software program of claim 1 wherein the 

2 instructions can be executed by a virtual machine running on 

3 a microprocessor residing on the resource-constrained 

4 device. 

1 10. The software program of claim 1 wherein the 

2 instructions can be executed on a portable smart card. 

ass. 

1 11. The software program of claim 1 wherein the 

J* 2 instructions can be executed by a device that supports 

3 multiple data types, wherein the sequence of instructions 
r| 4 includes data manipulation instructions, and wherein each 
H 5 data manipulation instruction is specific to a particular 
^ 6 data type . 

1 12 . The software program of claim 11 wherein the 

j| 2 data type associated with each data manipulation instruction 

tfl 3 is selected from among one of the following types: an 8 -bit 

4 signed two's complement integer numeric type, a 16-bit 

5 signed two's complement integer numeric type and a 32-bit 

6 signed two's complement integer numeric type. 

1 13 . The software program of claim 11 wherein the 

2 instructions can be executed by a device that supports 

3 multiple reference types and wherein each reference type is 

4 selected from among one of the following types: a class 

5 type, an interface type and an array type. 
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1 14 . The software program of claim 1 wherein the 

2 program includes at least one composite instruction for 

3 performing an operation on a current object. 

1 15. An application software program comprising an 

2 object-oriented, verifiable, type-safe and pointer-safe 

3 sequence of instructions residing on a computer- readable 

4 medium, wherein the program can be loaded to and executed by 

5 a resource-constrained device having random access memory 

6 with a capacity of no more than about 64 kilo-bytes. 

1 16. The software program of claim 15 wherein the 

2 program can be executed by a resource -constrained device 

3 having random access memory with a capacity of no more than 

4 about 4 kilo-bytes. 

1 17. The software program of claim 15 wherein each 

2 instruction includes an 8 -bit operation code. 

1 18. The software program of claim 15 wherein the 

2 sequence of instructions is hardware platform- independent . 

1 19. The software program of claim 15 wherein the 

2 instructions were converted from at least one Java class 

3 file and wherein at least some references to a constant pool 

4 were transformed to inline data. 

1 20. The software program of claim 19 wherein the 

2 instructions comprise operation codes and operands and 

3 wherein at least some references to the constant pool are 

4 inlined into operands in at least some of the instructions. 
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21. The software program of claim 19 wherein the 
instructions comprise operation codes and operands and 
wherein at least some references to the constant pool are 
inlined into operation codes in at least some of the 
instructions . 

22. The software program of claim 15 wherein the 
instructions can be executed by a virtual machine running on 
a microprocessor residing on the resource-constrained 
device . 

23. The software program of claim 15 wherein the 
instructions can be executed on a portable smart card. 

24. The software program of claim 15 wherein the 
instructions can be executed by a device that supports 
multiple data types, wherein the sequence of instructions 
includes data manipulation instructions, and wherein each 
data manipulation instruction is specific to a particular 
data type. 

25. The software program of claim 24 wherein the 
data type associated with each data manipulation instruction 
is selected from among one of the following types: an 8 -bit 
signed two's complement integer numeric type, a 16-bit 
signed two's complement integer numeric type and a 32-bit 
signed two's complement integer numeric type. 

26. The software program of claim 24 wherein the 
instructions can be executed by a device that supports 
multiple reference types and wherein each reference type is 
selected from among one of the following types: a class 
type, an interface type and an array type. 



1 27. The software program of claim 15 wherein the 

2 program includes at least one composite instruction for 

3 performing an operation on a current object. 

1 28. A resource-constrained device comprising: 

2 memory for storing an application software 

3 program comprising an object-oriented, verifiable, type-safe 

4 and pointer- safe sequence of instructions; 

5 random access memory having a capacity of no 

6 more than about 64 kilo-bytes; and 

7 a virtual machine implemented on a 

8 microprocessor wherein the virtual machine is capable of 

9 executing the sequence of instructions. 

1 29. The device of claim 28 wherein the 

2 microprocessor is based on an 8 -bit architecture. 

1 30. The device of claim 28 wherein the 

2 microprocessor is based on a 16-bit architecture. 

1 31. The device of claim 28 wherein each instruction 

2 includes an 8-bit operation code. 

1 32. The device of claim 28 wherein the sequence of 

2 instructions is hardware plat form- independent . 

1 33. The device of claim 28 wherein the instructions 

2 were converted from at least one Java class file and wherein 

3 at least some references to a constant pool are transformed 

4 to inline data. 
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1 34. The device of claim 33 wherein the instructions 

2 comprise operation codes and operands and wherein at least 

3 some references to the constant pool are inlined into 

4 operands in at least some of the instructions. 

1 35. The device of claim 33 wherein the instructions 

2 comprise operation codes and operands and wherein at least 

3 some references to the constant pool are inlined into 

4 operation codes in at least some of the instructions. 

1 36. The device of claim 28 wherein the virtual 

2 machine supports multiple data types, wherein the sequence 

3 of instructions includes data manipulation instructions, and 

4 wherein each data manipulation instruction is specific to a 

5 particular data type. 

1 37. The device of claim 28 wherein the program 

2 includes at least one composite instruction for performing 

3 an operation on a current object. 

1 38. A resource-constrained device comprising: 

2 memory for storing an application software 

3 program comprising an object-oriented, verifiable, type-safe 

4 and pointer- safe sequence of instructions; and 

5 a virtual machine implemented on a 

6 microprocessor that is based on an architecture of less than 

7 32 bits, wherein the virtual machine is capable of executing 

8 the sequence of instructions. 

1 39. A resource -constrained device comprising: 

2 memory for storing an application software 

3 program comprising an object-oriented, verifiable, type-safe 

4 and pointer- safe sequence of instructions; 
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5 random access memory having a capacity of no 

6 more than about 64 kilo-bytes; and 

7 a processor capable of executing the sequence 

8 of instructions. 

1 40. The device of claim 39 wherein the processor is 

2 based on an 8 -bit architecture. 

1 41. The device of claim 39 wherein the processor is 

2 based on a lS-bit architecture. 

1 42 . A resource- constrained device comprising: 

2 memory for storing an application software 

3 program comprising an object-oriented, verifiable, type -safe 

4 and pointer-safe sequence of instructions; 

5 random access memory having a capacity of less 

6 than about 64 kilo-bytes; and 

7 an application-specific integrated circuit 

8 (ASIC) capable of executing the sequence of instructions. 

1 43. The device of claim 42 wherein the ASIC is 

2 based on an 8 -bit architecture. 

1 44 . The device of claim 42 wherein the ASIC is 

2 based on a 16-bit architecture. 

1 45. A smart card comprising: 

2 memory for storing an application software 

3 program comprising an object-oriented, verifiable, type-safe 

4 and pointer- safe sequence of instructions; and 

5 a virtual machine implemented on a 

6 microprocessor, wherein the virtual machine is capable of 

7 executing the sequence of instructions. 
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46. The smart card of claim 45 wherein the virtual 
machine is substantially a Java Card virtual machine. 



1 47. The smart card of claim 45 wherein each 

2 instruction includes an 8 -bit operation code. 

1 48. The smart card of claim 45 wherein the sequence 

2 of instructions is hardware platform- independent . 

1 49. The smart card of claim 45 wherein the 

2 instructions were converted from at least one Java class 

3 file and wherein at least some references to a constant pool 

4 are transformed to inline data. 

1 50. The smart card of claim 45 wherein the 

2 instructions comprise operation codes and operands and 

3 wherein at least some references to the constant pool are 

4 inlined into operands in at least some of the instructions. 

1 51. The smart card of claim 45 wherein the 

2 instructions comprise operation codes and operands and 

3 wherein at least some references to the constant pool are 

4 inlined into operation codes in at least some of the 

5 instructions . 

1 52. The smart card of claim 45 wherein the virtual 

2 machine supports multiple data types, wherein the sequence 

3 of instructions includes data manipulation instructions, and 

4 wherein each data manipulation instruction is specific to a 

5 particular data type. 
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53. The smart card of claim 45 wherein the program 
includes at least one composite instruction for performing 
an operation on a current object. 



1 54 . A method of using an application software 

2 program including an object-oriented, verifiable, type-safe 

3 and pointer-safe sequence of instructions, the method 

4 comprising: 

5 receiving the software program in a resource - 

6 constrained device having random access memory with a 

7 capacity of no more than about 64 kilo-bytes; and 

8 executing the sequence of instructions on the 

9 resource-constrained device. 

1 55. The method of claim 54 further including: 

2 storing the sequence of instructions on the 

3 resource-constrained device. 

1 56. The method of claim 54 further including 

2 accessing the software program over a computer network prior 

3 to downloading the program onto the resource-constrained 

4 device. 

1 57. The method of claim 54 further including 

2 accessing the software program over the Internet prior to 

3 downloading the program onto the resource -constrained 

4 device. 

1 58. The method of claim 54 further including: 

2 transforming constant pool indices that appear 

3 in the received set of instructions to corresponding data 

4 values . 
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OBJECT-ORIENTED INSTRUCTION SET FOR 
RESOURCE -CONSTRAINED DEVICES 
Abstract 

A resource-constrained device such as a smart card 
5 or the like includes memory for storing an application 

software program comprising an object-oriented, verifiable, 
plat form- independent , type-safe and pointer-safe sequence of 
instructions. The device can also include a virtual machine 
implemented on a microprocessor where the virtual machine is 

10 capable of executing the sequence of instructions. Each 
instruction includes an operation code, and each data 
manipulation instruction is specific to a particular data 
type. The application program can be stored on a computer- 
readable medium prior to being received by the resource - 

15 constrained device. Methods of using such an application 
program, including accessing the program over the Internet 
and downloading it to a smart card, also are disclosed. 
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